docs(adr): ADR-0005 — operator alarm (value-threshold) model (#158 Phase 2)#239
Merged
Merged
Conversation
…#158 Phase 2) ADR-0005 (Proposed) resolves the #158 Phase 2 design question — "can the SettingsRegistry hold alarm thresholds?" — and lays out the alarm/event model for maintainer review before implementation. Key findings + recommendations (grounded, file:line-cited): - SettingsRegistry is scalar-only + global (no per-point dimension), so it CANNOT hold per-point thresholds — the issue's question answered "no". - No alarm/event/value-threshold model exists anywhere; freshness/attention-list is the only "abnormal point" surface and keys on arrival staleness, not value. - D1 thresholds: recommend twin per-point (bos:alarmHigh/Low [+warn]) projected like ControlSchema, with a SettingsRegistry scalar default; ControlSchema Min/Max (control-write bounds) intentionally not reused as alarm bounds. - D2 evaluation: Phase 2a derived-on-read (freshness-parallel pure classifier + batch-latest, zero new persisted model), Phase 2b background evaluator + event lifecycle (raise/clear/ack/history) → wires to the #162 notification policy. - D4 UI: extend the operator-home attention list with value-breach items, worst-first; a dedicated alarm route waits for Phase 2b (history/ack). Staged 2a → 2b → 2c (per-unit rule table), each independently valuable. Ends with Open Questions for maintainer decision. No production code — design note only. Refs #158 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XEG6csNA9GDkQzT37CwAUp Signed-off-by: Claude <noreply@anthropic.com>
This was referenced Jul 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
#158Phase 2 asks to introduce an alarm concept, and frames the core design question as "can the SettingsRegistry (#148) be extended to hold thresholds, or is something else needed?". This PR is the design note —docs/adr/0005-alarm-model.md, Status: Proposed. No production code; implementation is gated on the maintainer's answers to the Open Questions. Same design-first pattern as ADR-0004 (#230), which worked well.The ADR is grounded in the actual codebase (every claim file:line-cited), and answers the question:
Boolean/Number/String) and a flat global key→value map — it has no per-point dimension, so it cannot hold per-point alarm thresholds. That's the direct answer to the issue's question: no, not on its own.Recommendations laid out as Open Decisions for you to weigh:
bos:alarmHigh/Low[+warn]), projected likeControlSchema, with a SettingsRegistry scalar default. SettingsRegistry alone ❌.ControlSchema.Min/Max(control-write bounds) not reused as alarm bounds.batch-latest, zero new persisted model). Phase 2b: background evaluator + event lifecycle (raise/clear/ack/history → wires to #162 notification policy).Staged 2a → 2b → 2c (per-unit rule table + operator editing), each independently valuable and independently reviewable — the "軽量スライス先行" approach you endorsed for #158 Phase 1 and #230.
Test plan
SettingsRegistry, the freshness infra,batch-latest,ControlSchema, and the operator-home attention listChecklist
docs/adr/as ADR-0005🤖 Generated with Claude Code
Generated by Claude Code